Intermediate / 1 to 5 years experienced level questions & answers
Ques 1. Why Not Just Use a Debugger for Unit Testing?
* Automated unit testing requires extra time to setup initially. But it will save your time, if your code requires changes many times in the future.
* A debugger is designed for manual debugging and manual unit testing, not for automated unit testing. JUnit is designed for automated unit testing.
Ques 2. Why Not Just Write a main() Method for Unit Testing?
You can write a main() method in each class that needs to be tested for unit testing. In the main() method, you could create test object of the class itself, and write some tests to test its methods. However, this is not a recommended approach because of the following points:
* Your classes will be cluttered with test code in main method. All those test codes will be packaged into the final product.
* If you have a lots of classes to test, you need to run the main() method of every class. This requires some extra coding effort.
* If you want the test results to be displayed in a GUI, you will have to write code for that GUI.
* If you want to log the results of tests in HTML format or text format, you will have to write additional code.
* If one method call fails, next method calls won't be executed. You will have to work-around this.
Ques 3. Why Not Just Use System.out.println() for Unit Testing?
If we add debug statements into code, it is a low-tech method for debugging it. It usually requires that output be scanned manually every time the program is run to ensure that the code is doing what's expected.
It generally takes less time in the long run to codify expectations in the form of an automated JUnit test that retains its value over time. If it's difficult to write a test to assert expectations, the tests may be telling you that shorter and more cohesive methods would improve your design.
Ques 4. Under What Conditions Should You Test set() and get() Methods?
We should test to target areas that might break. set() and get() methods on simple data types are unlikely to break. So no need to test them.
set() and get() methods on complex data types are likely to break. So you should test them.
Ques 5. Can You Explain the Life Cycle of a JUnit3.8 Test Case Class?
Test case class contains a setUp() method, a tearDown() method and multiple testXXX() methods. When calling a test runner to run this test class, the runner will execute those methods in a specific order giving the test case class an execution life cycle like this:
setUp()
testXXX1()
tearDown()
setUp()
testXXX2()
tearDown()
Ques 6. How Often Should You Run Your JUnit Tests?
You should run all your unit tests as often as possible, ideally every time the code is changed. Make sure all your unit tests always run at 100%. Frequent testing gives you confidence that your changes didn't break anything and generally lowers the stress of programming in the dark.
For larger systems, you may just run specific test suites that are relevant to the code you're working on. Run all your acceptance, integration, stress, and unit tests at least once per day.
Most helpful rated by users:
- Who Should Use JUnit?
- What is JUnit?
- How To Compile a JUnit Test Class?
- Why Do You Use JUnit to Test Your Code?
- How To Write a Simple JUnit Test Class?